Repository navigation
Conversation
The tail guard used unroll_col_k, which is the gmem prefetch issue cursor. The prologue primes one buffer and each mainloop iteration issues one more ahead of consumption, so at loop exit unroll_col_k leads the accumulated K range by kStageCount * tileA_k_local. When floor(gemm_k / tileA_k_local) is a multiple of kStageCount and gemm_k is not tile aligned, the guard is false for every thread, process_tail_elements() is skipped, and up to a tile of K is dropped from the dot product. tile_idx advances by kStageCount per iteration and the FMA sequence within an iteration is unconditional, so tile_idx * tileA_k_local at loop exit is the K range that was accumulated. Use it as the tail origin. ptr_A and ptr_B are not advanced by the mainloop, so the absolute-K addressing inside process_tail_elements() is unaffected. ctest cases on example 91: k=1056, 1152 and 2176 fail before this change and pass after. k=288, 1280 and 1312 are controls against using total_tiles * tileA_k_local as the origin, which would double count. Addresses NVIDIA#3536, reported by @VaggelisGian. Not covered here: the same issue notes loads issued past the current K range. Since the FMA sequence is unconditional, the mainloop always runs a whole multiple of kStageCount tiles and accumulates past gemm_k when floor(gemm_k / tileA_k_local) % kStageCount != 0. Visible as wrong results for batch > 1, e.g. --m=256 --k=1280 --batch=2, and needs per-stage load/FMA predication.
Author
|
@Junkai-Wu Hi, could you take a look at this PR, or point me to the right reviewer? It fixes #3536: blockscaled GEMV drops part of the K tail when K is not tile-aligned and the tile count is a multiple of kStageCount, so the result is wrong. The PR adds ctest cases on example 91; the K=1056, 1152 and 2176 cases fail before the fix and pass after. Thanks! |
TANGBUDU
marked this pull request as draft
September 26, 2026 16:53
TANGBUDU
changed the title
TANGBUDU
marked this pull request as ready for review
September 26, 2026 17:38
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3536, fixes #3568.
The mainloop always consumes whole four-stage buffers. When the number of complete K tiles is not a multiple of
kStageCount, the extra stages either read past the end of K (into the next row or batch, or out of bounds) or reuse stale shared memory, and the scalar tail starts from the prefetch cursor instead of the end of the accumulated range. For example,--m=256 --k=1280 --batch=2fails verification and memcheck reports out-of-bounds global reads.Fix:
cp_async_zfill, so they add nothing in the FMA.mainloop_k.Writer ownership and synchronization are unchanged. Thanks to @VaggelisGian for the original report.
Tests: kept the 8 tail cases, added 6 stage-boundary cases with batch > 1, and added
--test-k-boundaries, which checks isolated last-tile/tail contributions and that changing batch 1 inputs does not change batch 0. All 15 pass on sm_120a with CUDA 13.0, and memcheck, racecheck and synccheck are clean on the boundary cases. In a 152-shape sweep, 149 pass, up from 54 on main, with no new failures. The remaining 3 (K=32/64, batch 2/8) go through the tail-only path, fail the same way on main, and are not touched here.Perf: register usage goes from 80 to 92, and aligned shapes pay a small cost. Paired CUDA Graph timings against the previous head on an RTX 5070 Ti Laptop (noisy, so treat as rough):
If that matters, a variant that keeps the old unpredicated loads when all four stages are valid gets back to 80 registers with identical results. Happy to switch to it.